REMARKS 



Claims 1-16 are pending. In the Final Office Action of October 15, 2008, claims 1-14 
and 16 were rejected under 35 U.S.C. § 102(e) as being anticipated by Mullen et al. (US 
2003/0140141 Al) ("Mullen"). Claim 15 was rejected under 36 U.S.C. § 103(a) as being 
unpatentable over Mullen. The Applicants respectfully traverse the rejections and request 
reconsideration in view of the following remarks. 

I. INTERVIEW SUMMARY 

On December 9, 2008, a telephonic interview was conducted between the undersigned 
and Examiners Ryan Jakovac and Azizul Choudhury. During the interview, the claimed 
limitations directed to the automated identification and configuration of devices for 
communications were discussed. The Examiner suggested amending the claims to indicate that 
the claimed device automatically configures itself to communicate with other identified devices 
when it has not been previously configured as such. 

II. REJECTIONS UNDER 35 U.S.C. § 102 

Claims 1-14 and 16 were rejected under 35 U.S.C. § 102(e) as being anticipated by 
Mullen. With this response, claims 1,7, 12 and 16 have been amended for clarity and not for 
reasons relating to patentability. No new matter has been added. 

Independent claims 1, 7, 12 and 16, as amended, are set forth above. 

Mullen discloses "[s]ystems and methods for enabling universal remote access and 
display of diagnostic images acquired by diagnostic imaging equipment, independent of the 
identity of the vendor that manufactured the equipment. One system includes a local area 
network; a scanner capable of sending objects formatted in accordance with a communications 
protocol, each object incorporating at least one image frame; and a data capture device connected 
to the local area network and programmed with data capture software to capture an object 
originating from the scanner in response to that scanner being specified as an object of diagnosis. 
This system further includes a communications channel, e.g., a virtual private network, for 
connecting the data capture device to a central service facility. The preferred communications 
protocol is DICOM. In response to an instruction from the service center, the data capture device 



7 



on the LAN captures image files from a malfunctioning scanner and forwards them to the service 
center for diagnosis" See Mullen, Abstract. 

Mullen fails to disclose at least "configuring, automatically, said first device to 
communicate substantially directly with said second device via said network when said first 
device is not already configured to communicate with said second device" as claimed in claim 1; 
"configuration logic coupled with said identification logic and operative to automatically 
configure said first diagnostic medical imaging device to communicate with said other diagnostic 
medical imaging devices which at least one of respond and identify themselves when said first 
diagnostic medical imaging device is not already configured to communicate with said other 
diagnostic medical imaging devices which at least one of respond and identify themselves" as 
claimed in claim 7; "each of said plurality of diagnostic medical imaging devices being operative 
to automatically discover at least one other of said plurality of diagnostic medical imaging 
devices via said network, automatically configure itself to communicate with any of the 
discovered at least one other of said plurality of diagnostic medical imaging devices, and 
facilitate communications therebetween" as claimed in claim 12; or "wherein each of said 
plurality of diagnostic medical imaging devices comprises means for automatically discovering 
at least one other of said plurality of diagnostic medical imaging devices via said network, 
automatically configuring itself to communicate with any of the discovered at least one other of 
said plurality of diagnostic medical imaging devices, and facilitating communications 
therebetween" as claimed in claim 16. 

Mullen discloses instead: 

In addition to storing images internally, modem imaging systems need to be able to 
transfer images to various types of remote devices via a communications network. To 
successfully transfer images, the relevant networking features of the scanner must be 
compatible with the networking features of the destination remote device. See Mullen, 
para. 5 (emphasis added). 

In order to accomplish image transfer, the imaging system must know the configuration 
of the destination remote device prior to attempting to communicate with that device. The 
configuration data for the destination remote device is typically inputted to the scanner 
during software installation by afield engineer, although the DICOM network can be 
configured at any time. When the scanner receives an instruction to transmit data to a 
particular remote device from the system operator, the scanner software converts the 
image data to be transferred into the DICOM format required by the destination remote 
device, based on the configuration data for that device stored in the imaging system 
memory. The scanner also sends a request over the network to the destination remote 
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device to open an association, i.e., to connect the scanner to the destination remote 
device. If the remote device responds in the affirmative, the scanner and remote device 
then agree on which device will act as the server and which as the client. The scanner 
also selects the appropriate encoding syntax from those accepted by the remote device. 
Other communication parameters are also negotiated. See Mullen, para. 7 (emphasis 
added). 

The scanner shown in FIG. 1 is designed to communicate with a configured remote 
device only if that device has been "activated". Activation causes the DICOM presets 
manager 30 to configure one of a multiplicity of DICOM tasks 40 in accordance with 
configuration data entered into the system for the associated remote device. That 
particular DICOM task will thereafter remain configured for that type of remote device 
until reconfigured for a different device. Other DICOM tasks are configured for other 
remote devices. See Mullen, para. 28 (emphasis added). 

In particular, a scanner can be configured to communicate with a DICOM-compatible 
computerized data capture device 52 connected to LAN 50. The data capture device 52 
has a DICOM interface 54 that enables it to send and receive DICOM objects to and from 
the LAN 50. See Mullen, para. 34. 

In particular, as shown by the excerpts above, Mullen merely discloses known manual 
configuration techniques for DICOM-compatible devices. Further, as Mullen is focused on 
sniffing or otherwise intercepting DICOM network communications for the purpose of 
diagnosing device failures, device-to-device configuration is largely ignored. 

The Examiner, without specificity, argues that the following paragraph of Mullen 

discloses Applicants' claims: 

The web server 76 may transmit and receive data to and from the scanners 64 via 
the network 74, and to and from the central service facility 66 through a firewall 
78, particularly with a Point-to-Point Protocol (PPP). Firewall 78 may include any 
of various known security devices for preventing access to central service facility 
66 except by recognized subscribers and other users. Central service facility 66 
includes one or more central computers 68 which coordinate data exchange 
between the scanners 64 and service support workstations 70 at the central service 
facility. Workstations 70 may, in turn, be staffed by service personnel. Computer 
68 may also be coupled for data exchange with one or more servers 72 at the 
central service facility. Moreover, computer 68 or other devices at the central 
service facility 66 may be coupled or configured to be coupled to other internal or 
external networks, such as for exchanging data with database 82 through an 
additional firewall 80. In the presently preferred configuration, database 82 may 
be local to or remote from the central service facility 66, and may contain data 
relating to the service history of particular scanners, families of scanners, and the 
like. Such data is compiled over time by transmission from computer 68, and is 
subsequently accessible by computer 68. See Mullen, para. 43. 
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However, contrary to the Examiner's assertions, the above excerpt generally describes 
the logical arrangement of devices in the disclosed network but fails to disclose any 
methodologies by which devices may be configured to communicate with other devices over a 
network as claimed. 

For at least these reasons, claims 1, 7, 12 and 16 are not anticipated, nor are they rendered 
obvious, by Mullen. Applicants therefore request that the Examiner withdraw this rejection of 
these claims. 

Claims 2-6, 8-11 and 13-14 depend from claims 1, 7 and 12 and are therefore allowable 
for the reasons set forth above with regard to these claims. Accordingly, Applicants request that 
the Examiner withdraw the rejections of claims 2-6, 8-11 and 13-14. 

III. REJECTIONS UNDER 35 U.S.C. § 103(a) 

Claim 15 was rejected under 35 U.S.C. § 103(a) as being unpatentable over Mullen. 
Claim 15 depends from claim 12 and is therefore allowable for the reasons set forth above with 
regard to this claim. Accordingly, Applicants request that the Examiner withdraw this rejection 
of claim 15. 



Each of the rejections in the Final Office Action October 15, 2008 has been addressed 
and no new matter has been added. The Applicant submits that all of the pending claims are in 
condition for allowance and notice to this effect is respectfully requested. The Examiner is 
invited to call the undersigned if it would expedite the prosecution of this application. 



CONCLUSION 



PLEASE MAIL CORRESPONDENCE TO: 



Respectfully Submitted, 
/RosaS. Kim/ 



Siemens Corporation 

Customer No. 28524 

Attn: Elsa Keller, Legal Administrator 

170 Wood Avenue South 

Iselin, NJ 08830 



Rosa S. Kim, Reg. No. 39,728 
Attomey(s) for Applicant(s) 
Telephone: 650-694-5330 
Date: Dec. 15, 2008 
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